In a computer application environment, each sound produced, for example by a user or the application, may be represented by a sound event or an audio stream or the like. A conventional technique for an application to produce multiple sounds at the same time is to individually and simultaneously play an audio file for each of the multiple sound events in separate “audio processing channels,” (e.g., input feeds or voices), where a limited number of audio processing channels are provided by the underlying computing system's audio hardware resources and audio software resources.
This conventional technique requires that the application load all of the audio files that are to be played at the same time (e.g., one for each sound event), into memory for use by the computing system's audio hardware and software resources, which mixes them into a fixed number of audio output channels (e.g., two output channels for stereo) and produces an analog signal for playing by the loudspeaker(s) without noticeable delay. The audio hardware and software of most computing systems provide several audio processing channel resources that can handle several play requests at a time, for example, on the order of 32, 64, or 128 audio processing channels that can play a similar number of simultaneous audio play requests. Thus, there are technical limitations on the number of audio files or sounds that can be played at the same time without changing the basic hardware resources and/or audio software resources of the underlying computing system.
For some applications that have large numbers of simultaneous users, however, such as large multi-player games (e.g., massively multiplayer online (MMO) games), there is a need to play a large number of sounds at the same time. Because of sound-generating actions performed by the many users (e.g., game players), such an application may require several hundreds, thousands, tens of thousands, or more audio events to be played simultaneously, and conventional hardware, audio software, and processing power resources cannot meet such an application's demands.
To cope, most conventional computing systems and audio subsystems are designed to drop sound-play requests according to a priority scheme when the maximum limit of simultaneous requests is exceeded. For example, if a computing system has audio processing channel resources that can play no more than 32 simultaneous sounds, then a request to play a 33rd sound while all 32 audio processing channels are busy will cause the system to identify the priority level associated with each of the 33 sounds and drop the lowest priority sound—i.e., not play the lowest priority sound or stop playing it, if it is already playing.
This causes undesirable effects. When the audio processing channels are full, a new request to play an audio file or sound will either not be played because it has a lower priority than all of the sounds in the channels that are being played already, or the system will abruptly stop a lower priority audio file that is currently being played, remove it from its audio processing channel, and place the new, higher-priority audio file into the freed audio processing channel and start it playing. This type of abrupt stop and switch is undesirably noticeable to listeners. This is particularly undesirable if the playing audio file that is stopped and preempted by a higher priority audio file contains background music, which the user is accustomed to hearing uninterrupted while using an application such as an MMO game.